В конце прошлой недели мы рассказали о документе, где приведено сравнение гипервизоров VMware vSphere, Microsoft Hyper-V и Red Hat Enterprise Virtualization (функциональность последнего там показана для бета-версии 3.1). На днях компания Red Hat объявила о выпуске окончательной версии платформы виртуализации Red Hat Enterprise Virtualization 3.1 для серверов и виртуальных ПК.
Напомним, что мы уже писали о возможностях версии 3.0, вышедшей в самом начале этого года, а вот что нового появилось в RHEV 3.1:
Поддержка до 160 виртуальных процессоров для ВМ
Поддержка до 2 ТБ оперативной памяти для ВМ
Поддержка последних линеек x86-процессоров
Live Snapshots - поддерживаются снапшоты работающих виртуальных машин
Улучшенный SPICE-клиент для работы с виртуальными ПК - нативная поддержка USB 2.0, в том числе для виртуальных машин Linux
Улучшения на дэшбоарде консоли управления в части статистической информации
Улучшения сетевого взаимодействия, включая горячее добавление/удаление виртуальных сетевых адаптеров (vNIC), поддержка bridge-less network (создание изолированных локальных сетей на хосте), зеркалирования портов (port mirroring), а также настройки MTU
Увеличенный объем поддерживаемых хранилищ, а также поддержка NFS v4
Технологическое превью механизма горячей миграции хранилищ ВМ Storage Live Migration
Улучшенный портал для пользователей с возможностью определения квот ресурсов для них (Technology Preview)
Новая политика виртуальных ПК "auto start"
Улучшения работы через WAN-соединения
Улучшенный Virtual Desktop Client
Интеграция с Red Hat Storage (содержащего GlusterFS тома)
Командный интерфейс с использованием REST API
Пакет разработки Python SDK с использованием REST API
Механизм Windows Driver Deployment для гостевых ОС
Правила фильтрации через механизм Default Network Filter (nwfilter) для виртуальных машин
В принципе, весьма немало. Скачать пробную версию решения Red Hat Enterprise Virtualization 3.1 можно по этой ссылке. Документ с полным описанием новых возможностей RHEV 3.1 доступен тут.
Давно мы что-то не писали про сравнения платформ виртуализации, которые, зачастую, сильно попахивают предвзятостью и переворачиванием фактов. Но на этот раз мы бы хотели отметить одно из немногих достаточно независимых сравнений "Enterprise Hypervisor Comparison", в котором автор сам явно указывает, что идеального продукта для любой инфраструктуры нет. Особенно если брать в расчет стоимость решения.
В документе рассмотрены следующие платформы виртуализации в различных аспектах функциональности, необходимой для среднего и крупного предприятия:
VMware vSphere 5.1
Microsoft Windows/Hyper-V Server 2012
Red Hat Enterprise Virtualization 3.1 (на данный момент в стадии беты)
Для Windows Server 2012 и Hyper-V данные приведены с учетом Microsoft System Center 2012
Service Pack 1, который еще не выпущен, о чем в документе сделана специальная пометка. Надо отметить, что автор рассматривал только полнофункциональные версии продуктов и не рассматривал их бесплатные версии.
В целом, получилось неплохое сравнение, которое, однако, нельзя рассматривать как единственный источник информации при выборе решения.
Привет. Меня зовут Александр Самойленко, и ровно 6 лет назад я начал писать на VM Guru о технологиях виртуализации и виртуальных машинах. В то время это был жиденький сайтик на крякнутой CMS-ке, с которой было временами очень сложно бороться. Тогда я работал в Veeam Software (это даже был еще не совсем Вим), про виртуальные машины в России еще знали мало, а тема виртуализации для многих была такой же далекой, как перспективы будущего в мини-сериале "Black Mirror" для современного человека. Но уже тогда в крупных российских энтерпрайзах инженеры крутили различные платформы виртуализации, лучшей из которых была VMware ESX Server (а многие, конечно же, помнят и Workstation начала двухтысячных - вау! компьютер в компьютере!).
Первый год на наш сайтик ходило 50-100 человек, писал я просто так для себя, а виртуальными машинами не занимался вовсе. Тогда же писал и статьи на iXBT (написал их аж где-то 20-30 штук, из которых мне самому понравилась тогда только вот эта). И да, в российском VMware тогда работал 1 (один) человек - старожилы помнят, кто это был.
Но потом интерес к виртуализации (тогда это было равно VMware для x86-платформ) стал сильно возрастать. Паша Новиков начал ездить на семинары, а мы тогда выпытывали у него, как нужно эстимировать проекты по виртуализации, хотя, конечно же, тогда еще он знал не больше нашего:). В VMware уже работало целых 3 человека (привет Юля и Виталик!). А мы с крякнутой CMS-ки переехали на самописный движок.
Ну а потом мы делали много чего - открыли компанию, сделали, наверное, самый большой на то время проект по виртуализации в России (нормальный был проект, ответственно подходили), женились, разводились, заводили детей. Так вот и прошли 6 лет или, если измерять по-другому - 2300 заметок. Все еще впереди.
Мы уже писали о некоторых функциях утилиты esxcli в VMware vSphere, которая работает с различными пространствами имен, такими как network, storage, hardware и прочими. Сегодня мы хотим остановиться на новых функциях по управлению устройствами ввода-вывода I/O Device Management (IODM), пространство имен для которых появилось в VMware vSphere 5.1. Цель этих новых инструментов - дать администратору инструменты для понимания уровня, на котором происходят проблемы с хранилищем в сети SAN (см. тут).
Это новое пространство имен выглядит вот так:
esxcli storage san
Например, мы хотим сделать Reset для FC-адаптера:
esxcli storage san fc reset -A vmhba3
А потом посмотреть его лог, который включает в себя информацию о таких событиях, как разрыв соединения:
esxcli storage san fc events get
Можно собрать статистику по iscsi-адаптеру командой:
esxcli storage san iscsi stats get
Кроме того, в VMware vSphere 5.1 появились функции мониторинга твердотельных накопителей - SSD Monitoring, реализуемые метриками, которые собирает каждые полчаса демон S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Находятся стандартные плагины в /usr/lib/VMware/smart_plugins (кстати, вендоры дисковых устройств могут добавлять туда свои плагины вместо имеющихся generic-плагинов). Надо также отметить, что эти метрики не передаются в vCenter и доступны только через esxcli.
Посмотреть статистики SSD-дисков можно командой:
esxcli storage core device smart get -d naa.xxxxxx
Жирным выделены метрики, которые могут оказаться полезными. Параметр Reallocated Sector Count не должен сильно увеличиваться со временем для исправных дисков. Когда дисковая подсистема получает ошибку read/write/verification для сектора, она перемещает его данные в специально зарезервированную область (spare area), а данный счетчик увеличивается.
Media Wearout Indicator - это уровень "жизни" вашего SSD-диска (для новых дисков он должен отображаться как 100). По мере прохождения циклов перезаписи диск "изнашивается" и данный счетчик уменьшается, соответственно, когда он перейдет в значение 0 - его жизнь формально закончится, исходя из рассчитанного для него ресурса. Кстати, этот счетчик может временно уменьшаться при интенсивных нагрузках диска, а потом восстанавливаться со временем, если средняя нагрузка на диск снизилась.
Новые возможности VMware vCenter Operations Manager 5.6:
Полная поддержка vCenter Server 5.1 и ESXi 5.1
Интеграция со средством vCenter Infrastructure Navigator, позволяющая предоставлять информацию о жизнедеятельности инфраструктуры в интерфейс Operations Manager
Интеграция с продуктом vCenter Configuration Manager, позволяющая получать в интерфейсе Operations Manager группы виртуальных машин, созданные в vCCM
Интеграция с VMware vSphere Web Client
Поддержка кастомных групп, создаваемых пользователем
Улучшения движка анализа аппаратных мощностей
Улучшения механизмов обработки численных параметров и средств обнаружения проблем
Контекстные подсказки для операций с виртуальными машинами, хостами, хранилищами и кластерами
В этой статье мы расскажем о новых возможностях, которое приобрело это средство номер 1 для создания iSCSI-хранилищ под виртуализацию Hyper-V.
Итак, что нового:
Много улучшений High Availability. Во-первых, улучшился уровень юзабилити - теперь интерфейсы выглядят проще и работают быстрее. Многие операции снабжены мастерами. Во-вторых, улучшился движок HA - теперь можно производить операции add, remove
и switch для HA-узла без вывода его в режим "Offline".
Новые функции HA-устройств. Теперь в качестве HA-устройств могут быть использованы такие девайсы как deduplicated, thin-provisioned IBV или
DiskBridge. Это означает, что теперь доступна функциональность дедупликации, thin provisioning, снапшоты и прочее для HA-устройств.
Улучшения дедупликации:
Asynchronous replication of deduplicated data - теперь данные для репликации по медленным каналам (WAN) могут передаваться асинхронно, что позволяет использовать решение в DR-сценариях. Кроме того, теперь любой тип устройства может быть целевым для репликации.
Deletion of unused data - неиспользуемые блоки, появляющиеся на дедуплицируемом хранилище, записываются актуальными данными, что позволяет использовать пространство более эффективно.
Decreased memory usage - в этой версии StarWind Native SAN на 30% снижены требования к памяти сервера. Теперь при использовании блоков 4 KB только 2 МБ оперативной памяти требуется на 1 ГБ хранимых данных.
Полная поддержка Windows Server 2012.
Скачать StarWind Native SAN for Hyper-V 6.0 можно по этой ссылке. И напоминаем, что у этого решения есть полнофункциональная бесплатная версия.
Недавно компания HP выпустила первую версию продукта Virtualization Performance Viewer 1.0, предназначенного для обнаружения, диагностики и решения проблем в виртуальных средах. Virtualization Performance Viewer поставляется в бесплатном (ограниченная функциональность) и коммерческом изданиях.
HP Virtualization Performance Viewer поддерживает гипервизоры VMware vSphere и Microsoft Hyper-V, и доступен как виртуальный модуль (Virtual Appliance) на базе CentOS. Бесплатная версия также доступна как приложение для ОС Windows.
Основные возможности продукта:
Просмотр состояния и производительности виртуальной инфраструктуры, а также предоставление информации о ее компонентах в виде "Treemaps"
Утилиты для диагности и решения проблем с описанием возникших неполадок
Возможность предвидеть проблемы недостатка мощностей, а также идентифицировать недогруженные и перегруженные системы
Отличия бесплатного и коммерческого изданий:
Скачать HP Virtualization Performance Viewer можно по этой ссылке.
На днях компания Код Безопасности объявила о том, что сертификат ФСТЭК России на ПАК «Соболь» версии 3.0 был продлен до 07 декабря 2015 года. Сертификат подтверждает, что ПАК «Соболь версии 3.0 соответствует 2-му уровню контроля на отсутствие НДВ (в соответствии с требованиями РД Гостехкомиссии России) и может использоваться в автоматизированных системах до класса 1Б и в ИСПДн до класса К1 включительно.
ПАК «Соболь» версии 3.0 предназначен для реализации следующих защитных механизмов:
идентификация и аутентификация пользователей на входе в систему (непосредственно при запуске сервера);
ведение журнала безопасности;
сигнализация попыток нарушения защиты;
запрет загрузки с внешних носителей;
контроль конфигурации (PCI-устройств, ACPI, SMBIOS и оперативной памяти).
Более подробно о комплексе ПАК "Соболь" можно узнать по этой ссылке.
Как многие знают, ядром концепции компании Citrix является идеология предоставления доступа пользователя к своим данным и приложениям из любой точки и с любого устройства.
На днях эта концепция дала сбой - из-за багов приложение Citrix Receiver 5.6.3, выпущенное 28 ноября под iOS, было удалено из App Store.
Потенциально это событие может может повлиять на те компании, в которых CIO убедили пользователей и руководство, что с помощью Citrix XenDesktop/XenApp можно быстро получать доступ к данным своего ПК cо своих iPad и iPhone. Они рассказали о всех модных фишках продукта, включая MDX и ShareFile, а теперь это приложение нельзя никак получить уже несколько дней!
Интересно то, что это так называемый "distribution bug" - то есть ошибка, не касающаяся непосредственно функциональности приложения, а касается она возможностей доступа к данным, сохраненным предыдущей версией Citrix Receiver на iOS-устройстве. Соответственно, после преодоления бюрократической машины Apple, с выпуском исправленной версии Receiver, эта ошибка в скором времени будет исправлена. На момент написания заметки (0:20 мск, 3 декабря) по запросу "Citrix" в App Store приложение Receiver так и не находилось.
Таким образом, за последнее время слажали все три основных вендора в сфере виртуализации:
Продолжаем рассказывать о компании ИТ-ГРАД - первом облачном провайдере России, предоставляющем виртуальные машины VMware vSphere в аренду для организаций различного масштаба, являющейся также и системным интегратором. Специально под задачу создания виртуальной инфраструктуры ИТ-ГРАД разработала комплекты оборудования, сбалансированные по таким показателям как:
цена
производительность
надёжность
Предлагаемые системы позволяют полностью развернуть информационно-техническую инфраструктуру организации на 50-500 пользователей, включая следующие сервисы:
Доменная инфраструктура: MS Windows Server 2008R2 (DC, DNS, RADIUS, DHCP)
Электронная почта: MS Exchange Server 2010 (Relay, Exchange MBX, HT, CAS, TMG)
Объединенные коммуникации: MS Lync (Edge, FE, MS SQL)
Внутрикорпоративный портал MS SharePoint 2010
Инфраструктура открытых ключей (PKI) с возможностью обеспечения аутентификации 802.1x в проводной и беспроводной сети (Root CA0, Issuing CA1)
Комплексы укомплектованы всем необходимым для начала работы и не требуют дополнительного оборудования. Опциональные возможности позволяют легко наращивать производительность любого комплекса, либо изменять его качественные характеристики.
Для мониторинга инфраструктуры виртуализации VMware vSphere зачастую используется протокол SNMP (например, через серверы Open NMS , CACTI , PRTG и т.п.). До версии VMware vSphere 5.1 поддерживались только версии 1 и 2 протокола SNMP. С выпуском версии 5.1 была добавлена поддержка третьей версии этого протокола (SNMPv3), который имеет множество улучшений, в основном касающихся безопасности.
Также в процессе настройки SNMP на хостах ESXi можно выбрать способ приема агентом сообщений: от IPMI-сенсоров (как в прошлых версиях ESXi) или CIM-индикаторов. Кроме того, можно фильтровать отсылаемые на сервер мониторинга SNMP-сообщения.
Для настройки протокола SNMP версий 1 и 2 нужно сделать 4 простых шага:
1. Установить community string (по сути, это пароль) командой:
esxcli system snmp set –communities public
2. Установить сервер мониторинга (SNMP target), который включает адрес и порт, а также community string:
esxcli system snmp set –targets server.domain@161/public
3. Включить сервис SNMP на хосте ESXi:
esxcli system snmp set –enable true
4. Протестировать конфигурацию:
esxcli system snmp test
Для того, чтобы протестировать SNMP со стороны таргета можно использовать команду (для версии 2):
snmpwalk -v2c -c public esxserver.domain
Для настройки протокола SNMP версии 3 нужно сделать 8 шагов (не все обязательны):
1. Выставляем Engine ID для SNMP-агента (ID - это шестнадцатиричное значение от 5 до 32-х разрядов длиной):
esxcli system snmp set –engineid 766d77617265
2. Выставляем протокол аутентификации (SHA1, MD5 или none):
esxcli system snmp set –authentication SHA1
3. Устанавливаем протокол шифрования:
esxcli system snmp set –privacy AES128
4. Если мы включили протоколы шифрования в шагах выше, то нужно сгенерировать хэши для паролей аутентификации и шифрования (опция -r означает, что пароли вводятся прямо в команде):
esxcli system snmp hash -r -A pass1 -X pass2
5. Настраиваем пользователя SNMP, указывая хэши, полученные в предыдущей команде (user - ваш пользователь):
esxcli system snmp set –users user/f9f7311379046ebcb5d134439ee5b7754da8a90f/d300f16eec59fb3b7ada7844ff764cbf4641fe5f/priv
6. Устанавливаем SNMP-таргет:
esxcli system snmp set –v3targets server.domain@161/user/priv/trap
7. Включаем SNMP:
esxcli system snmp set –enable true
8. Тестируем настройки:
esxcli system snmp test
Точно так же, как и для версий 1 и 2, со стороны сервера можно проверить работоспособность настроек SNMP, указав введенные ранее пароли:
snmpwalk -v3 -u user -l AuthPriv -a SHA -A pass1 -x AES -X pass2 esxserver.domain
Все вышеперечисленное можно сделать и через vSphere CLI (нужно ставить на отдельную машину) в интерактивном режиме с помощью скрипта vicfg-snmp.pl:
Если вам не хочется заморачиваться с установкой vSphere CLI, то можно использовать скрипт configureSNMPv3.sh, с помощью которого настройка происходит легко и просто:
Продолжаем вас знакомить с продуктом номер 1 - vGate R2, предназначенным для защиты виртуальных сред VMware vSphere. Напомним, что он позволяет производить автоматическую настройку конфигурации безопасности хост-серверов VMware ESX / ESXi средствами политик, защищать инфраструктуру от несанционированного доступа, а также имеет все необходимые сертификаты ФСТЭК (включая сертификаты на vSphere 5.0). Недавно мы писали о том, что продукт vGate R2 удобно применять совместно с решением Secret Net для защиты гостевых ОС виртуальных машин.
Кроме того, если на рабочем месте администратора VMware vSphere установлена система Secret Net 5.1 или выше, то для аутентификации пользователя возможно использование персонального идентификатора (e-token).
Перед его использованием на рабочем месте необходимо выполнить предварительные настройки:
1. Выполните инициализацию персонального идентификатора в Secret Net согласно документации на него.
2. Подключите персональный идентификатор к ПК.
3. Запустите агент аутентификации (см. стр. 8).
4. Введите имя и пароль пользователя, отметьте поле "Входить в систему автоматически" и нажмите кнопку "Подключиться".
После этого пароль будет сохранен в персональный идентификатор (e-token) и для администрирования VMware vSphere при последующих запусках vSphere Client больше вводить никаких дополнительных паролей не придется (при условии подключенного токена).
Недавно компания VMware разослала своим клиентам и партнерам письмо, в котором сообщалось об окончании поддержки линейки VMware vSphere 4.x, построенной, в том числе, на базе "толстого" гипервизора VMware ESX. Теперь эта новость доступна на официальном сайте VMware.
Дата окончания продаж vSphere 4.x: 15 августа 2013 г.
В связи с этим пользователям до 15 августа следующего года рекомендуется создать или сохранить резервную копию соответствующих дистрибутивов и сформировать необходимые лицензионные ключи на портале My VMware для поддержки или расширения сред на базе гипервизора vSphere ESX версии 4.x или vMA версий 1 и 4. Эти операции необходимо выполнить до 15 августа 2013 г. Компания VMware не будет предоставлять никакие двоичные файлы (дистрибутивы, утилиты и т.п.) и лицензионные ключи для гипервизора vSphere ESX 4.x и для vMA версий 1 и 4 после 15 августа 2013 г.
Касательно поддержки (SnS) и жизни после 15 августа:
Жизненный цикл поддержки гипервизора vSphere ESX 4.X и vMA.
Датой окончания поддержки остается 21 мая 2014 г. Подробнее о жизненном цикле поддержки VMware.
Возможность использования заказчиками гипервизора vSphere ESX 4.x или vMA версий 1 и 4 после 15 августа 2013 г.
Заказчики сохраняют возможность использования лицензированных копий продукта после даты окончания продаж и даты окончания поддержки. Тем не менее они не смогут загружать дистрибутивы и формировать новые лицензионные ключи после даты окончания продаж и получать техническую поддержку и подписку после даты окончания поддержки.
Продажа и поддержка vSphere ESXi 4.X — БЕЗ изменений.
Продажа vMA 4.1, 5 и 5.1 и поддержка всех версий — БЕЗ изменений.
На днях сообщество разработчиков Xen объявило о выпуске обновленной версии платформы Xen Cloud Platform 1.6 (XCP), которая предназначена для управления облачной инфраструктурой на базе гипервизора Xen (в каком-то смысле это аналог коммерческого XenServer). Напомним, что о решении Xen Cloud Platform версии 1.1 мы уже писали годом ранее, а в стадии беты версия 1.6 уже находилась с октября этого года.
XCP построена на базе свободного гипервизора Xen (в новой версии - 4.1.3), к которому прилагаются различные возможности для построения облачных инфраструктур посредством Xen API toolstack. Платформа XCP распространяется под лицензией GNU General Public License (GPL2).
Технология Storage XenMotion, позволяющая проводить миграцию работающих виртуальных машин на другой хост и хранилище, при этом хосты могут быть в разных пулах и не иметь общего хранилища, т.е. горячая миграция ВМ доступна между локальными дисками хост-серверов.
Технология Live Virtual Disk Image migration, предоставляющая возможности миграции ВМ без ее выключения.
Улучшения сетевого взаимодействия:
Поддержка Link Aggregation Control Protocol (LACP)
Ubuntu 10.04, Debian Squeeze, Oracle EL 6.0, SLES 10 SP4
Ubuntu 12.04, RHEL/CentOS 6.2, Oracle EL 6.1 & 6.2, Windows 8
В целом с версии 1.1 платформа XCP 1.6 получила немало новых функций (релизная версия 1.5 так и не была выпущена), поэтому некоторые сервис-провайдеры и крупные организации могут уже начать задумываться о построении инфраструктуры на базе этого решения. Более подробно о новой версии Xen Cloud Platform 1.6 рассказано тут, а по этой ссылке ее можно скачать.
Некоторые из вас, вероятно, видели документ, называющийся "VMFS File Locking and Its Impact in VMware View 5.1", доступный у нас вот тут. Он вкратце рассказывает о нововведении в VMware View 5.1 - теперь для пулов связанных клонов (Linked Clones) можно использовать кластеры до 32-х хостов, а не 8 как раньше. Но работает это только для тех окружений, где реплика базового образа размещена на NFS-хранилище, для VMFS же хранилищ ограничение осталось тем же самым - кластер из максимум 8 хостов. Давайте разбираться, почему это так.
Во-первых, посмотрим как выглядит классическая структура связанных клонов в инсталляции VMware View:
В пуле связанных клонов, который мы можем построить с помощью VMware View Composer, находится создаваемый и настраиваемый базовый образ (может быть со снапшотом), из которого создается реплика этой ВМ (Replica), на базе которой из дельта-дисков строятся уже конечные десктопы пользователей. При этом данные реплики используются одновременно всеми связанными клонами, которые располагаются на хост-серверах ESXi кластера.
Теперь напомним, что мы уже рассматривали типы блокировок (локов) в кластерной файловой системе VMFS. Однако там рассмотрены не все блокировки, которые могут быть применены к файлам виртуальных дисков. Мы рассматривали только эксклюзивную блокировку (Exclusive Lock), когда только один хост может изменять VMDK-файл, а все остальные хосты не могут даже читать его:
Такие блокировки используются в традиционном окружении инфраструктуры виртуализации для серверной нагрузки в виртуальных машинах. Очевидно, что такие блокировки не подходят для доступа к данным файла виртуального диска реплики VMware View.
Поэтому есть и другие типы блокировок. Во-первых, Read-Only Lock (в этом режиме все хосты могут читать один VMDK, но не могут менять его):
Во-вторых, Multi-Writer Lock:
В режиме такой блокировки сразу несколько хостов могут получить доступ к VMDK-файлу на общем хранилище VMFS в режиме Read/Write. При использовании инфраструктуры связанных клонов на хранилище применяются локи типа Read-Only Lock и Multi-Writer Lock, что требует одновременного доступа нескольких хостов ESXi к одному файлу. Естественно, где-то в локе должны храниться данные о том, какие хосты используют его.
А теперь посмотрим на внутренности лока. Они как раз и содержат все UID (User ID) хостов, которые работают с VMDK-файлом, в структуре "lock holders". Надо отметить, что для работы автоматической процедуры обновления лока необходимо, чтобы его размер был равен одному сектору или 512 байтам. А в этот объем помещается только 8 этих самых UID'ов, а девятый уже не влезает:
Напомню, что мы говорим про диск реплики, который необходим сразу всем хостам кластера с виртуальными ПК этого пула. Поэтому, как и раньше, в VMware View 5.1 нельзя использовать для реплики, размещенной на томе VMFS, кластер из более чем восьми хост-серверов VMware ESXi.
Однако можно поместить реплику на том NFS. По умолчанию протокол NFS не поддерживает file locking, однако поддерживает механизм Network Lock Manager
(NLM), который использует схему блокировок "advisory locking":
В этой схеме клиенты файла NFS могут координировать между собой совместный доступ к файлу (в нашем случае - VMDK). При этом никакого лимита на 8 хостов в этом механизме нет. Однако раньше в VMware View не позволялось использовать более 8 хостов в кластере для пула связанных клонов.
Теперь это сделать можно и, во многих случаях, даже нужно, выбрав NFS-хранилище для пула Linked Clone:
Там собственно и будут раскрыты все новые возможности этого решения, у которого есть еще и полнофункциональная версия StarWind Native SAN for Hyper-V Free Edition, ограниченная лишь объемом хранилища (128 ГБ).
Некоторое время назад компания VMware открыла регистрацию пользователей для приема заявок на доступ к порталу лабораторных работ VMware Hands-On Labs (HOL), которая доступна по этой ссылке (нужно указывать корпоративный email). Эти лабораторные работы (которые в большом количестве проводились на конференциях VMware VMworld) позволяют приобрести практический опыт по управлению элементами инфраструктуры VMware vSphere и другими решениями (VMware View, vCloud Director), а также получить новые технические знания на достаточно глубоком уровне - и все это онлайн, бесплатно и без необходимости покупать серверы для обучения и настраивать там соответствующие компоненты.
Недавно компания VMware объявила о том, что публичная бета-версия Hands-On Labs уже запущена, а приглашения уже начали поступать некоторым пользователям. Если вы зарегистрировались ранее, то логины и пароли должны прийти в течение последующих нескольких дней. Для новых пользователей регистрация по-прежнему доступна.
Проводимые лабораторные работы будут полезны также и для тех пользователей, кто уже применяет VMware vSphere, так как там рассматриваются различные Enterprise-компоненты платформы, такие как распределенный коммутатор vSphere Distrinuted Switch (vDS), которые могут быть не развернуты или не использоваться в производственной среде предприятия. Кроме того, лабы HOL могут оказаться полезными при подготовке к экзаменам по линии сертификации VMware Certified Professional.
Для примера название лабораторной работы: HOL-INF-02 – Explore vSphere 5.1 Distributed Switch (vDS) New Features. Полное описание лабораторных работ доступно по этой ссылке.
Мы уже много писали о продукте номер 1 - vGate R2, который необходим для защиты виртуальной инфраструктуры VMware vSphere средствами политик безопасности и механизмов защиты от несанкционированного доступа (НСД). С точки зрения защиты от НСД, продукт vGate R2 защищает хост-сервры виртуализации и виртуальные ресурсы (хранилища, сети, ВМ, сетевые адаптеры), которые делятся на изолированные домены безопасности в соответствии с назначенными им иерархическими и плоскими метками (2 независимых системы разделения ресурсов):
Однако vGate R2 (как, во многом, и сама платформа vSphere) рассматривает виртуальные машины как "черные ящики", внутри которых установлены различные операционные системы, которые, между тем, нуждаются в защите. Поэтому для этих целей требуются дополнительные средства защиты от НСД в корпоративной инфраструктуре, которые помогут обеспечить безопасность на уровне ОС Windows для рабочих станций, а также виртуальных и физических серверов.
Здесь вам может оказаться полезным продукт Secret Net, который является сертифицированным средством защиты информации от несанкционированного доступа и позволяет привести автоматизированные системы в соответствие требованиям регулирующих документов:
№98-ФЗ ("О коммерческой тайне")
№152-ФЗ ("О персональных данных")
№5485-1-ФЗ ("О государственной тайне")
СТО БР (Стандарт Банка России)
Возможности Secret Net 6 для гостевых ОС виртуальных машин:
Контроль каналов распространения конфиденциальной информации.
Контроль устройств компьютера и отчуждаемых носителей информации на основе централизованных политик, исключающих утечки конфиденциальной информации.
Централизованное управление политиками безопасности, позволяет оперативно реагировать на события НСД.
Оперативный мониторинг и аудит безопасности.
Масштабируемая система защиты, возможность применения Secret Net (сетевой вариант) в организации с большим количеством филиалов.
Варианты развертывания Secret Net 6
Автономный режим – предназначен для защиты небольшого количества (до 20-25) рабочих станций и серверов. При этом каждая машина администрируется локально.
Сетевой режим (с централизованным управлением) – предназначен для развертывания в доменной сети c Active Directory. Данный вариант имеет средства централизованного управления и позволяет применить политики безопасности в масштабах организации. Сетевой вариант Secret Net может быть успешно развернут в сложной доменной сети (domain tree/forest).
Совместное применение продуктов vGate R2 и Secred Net от одного вендора - Кода Безопасности - позволит надежно контролировать все аспекты безопасности, связанные с риском несанкционированного доступа к данным на различных уровнях: хост-серверов и виртуальных машин (vGate R2) и гостевых ОС (Secred Net).
На прошедшем VMworld Europe 2012 компания VMware рассказала об интересном решении VMware View Agent Direct-Connection Plugin, которое позволит пользователям виртуальных ПК соединяться с ними напрямую, минуя брокер соединений VMware View Connection Server. Делается это решение в партнерстве с различными компаниями, такими как Dell (+Quest) и Navisite, предлагающими DaaS-решения (Desktop-as-a-Service). Вот, например, интервью на эту тему с CEO компании Desktone, которая является провайдером DaaS:
Технически на данный момент View Agent Direct-Connection Plugin представляет собой DLL-ку, которая помещается в туже директорию, что и VMware View Agent, устанавливаемый на десктопе. После чего с ним можно соединяться напрямую, без брокера (т.е. просто вбив IP-адрес машинки или ее имя в клиенте):
Такую DLL мы помещаем в базовый образ, после чего при запуске агента во всех виртуальных ПК на базе этого образа происходит инициализация плагина View Agent Direct-Connection. Надо отметить, что при соединении пользователя из любого клиента (Windows, Mac, Android, iPad, Teradici Zero Clients и др.) через этот плагин, поддерживаются все необходимые функции VMware View: высокопроизводительный протокол PCoIP, перенаправление USB-устройств, поддержка 3D rendering, SSL-сертификаты, разделение GPU и так далее.
Кому такое может пригодиться? Я вижу такие варианты применения VMware View Agent Direct-Connection Plugin:
Использование со стороны DaaS-провайдеров для предоставления доступа отдельным пользователям, в том числе для тестирования сервисов.
Применение в небольших компаниях, которые не покупают VMware View, но используют виртуальные ПК на платформе VMware vSphere.
Интеграция в сторонних решениях, которые используют технологии VMware View и консоль виртуального ПК.
На данный момент VMware View Agent Direct-Connection Plugin работает только под Windows 7 и Windows 8 и доступен только партнерам VMware для собственных нужд. О публичной доступности продукта будет объявлено дополнительно.
Продолжаем рассказывать о мероприятиях компании ИТ-ГРАД - первого облачного провайдера России, предоставляющего виртуальные машины VMware vSphere в аренду для организаций различного масштаба.
По статистике 80% компаний не имеют плана аварийного восстановления, либо вообще не делают резервного копирования. Цель проводимого семинара "Обеспечение непрерывности бизнеса: облачное резервное копирование" - предоставить возможность узнать о варианте построения плана аварийного восстановления и защиты бизнеса на базе публичных облаков.
В рамках семинара, который пройдет 14 декабря в Санкт-Петерубрге, будут рассмотрены следующие темы:
Как наладить резервное копирование не по остаточному принципу.
Три уровня защиты непрерывности бизнеса.
Критерии определения бюджета на организацию плана аварийного восстановления.
Резервное копирование как первый шаг на пути в публичное облако.
Сценарии использования облачного резервного копирования.
Модель предоставления сервиса облачного резервного копирования.
Запустится ли резервная копия? Границы ответственности сервис-провайдера, SLA.
Приходите - будет интересно. Тема резервного копирования в облаке всегда интересна и актуальна. Зарегистрироваться на мероприятие можно по этой ссылке.
Не так давно мы писали о планируемом VMware продукте VMware vCenter Multi-Hypervisor Manager (MHM), который позволяет управлять серверами и виртуальными машинами на платформе Hyper-V. На днях компания VMware выпустила первую версию плагина Multi-Hypervisor Manager, который, конечно же, не поддерживает Hyper-V 3.0 в Windows Server 2012 (конечно же - потому что VMware в последнее время взяла моду выпускать продукты без поддержки последних версий). Однако, вроде бы, в скором времени обещают версию и под новый Hyper-V.
VMware vCenter Multi-Hypervisor Manager поставляется в виде плагина к "толстому" клиенту vSphere Client (Web Client не поддерживается), который предоставляет доступ к дереву объектов Microsoft Hyper-V на базе следующих ОС:
Microsoft Hyper-V Server 2008
Microsoft Hyper-V Server 2008 R2
Напомним, что, согласно архитектуре решения, MHM имеет не только клиентскую часть, но и серверный компонент:
Для установки серверной части потребуются следующие вычислительные ресурсы:
2 CPU на частоте 2 ГГц или более
4 ГБ памяти
1 ГБ дискового пространства
Сетевой адаптер
Между всеми компонентами данной архитектуры осуществляется безопасная коммуникация по HTTPS.
Надо отметить, что серверная часть Multi-Hypervisor Manager - это Windows-приложение, поэтому если вы используете, например, виртуальный модуль VMware vCenter Server Appliance (vCSA), то придется устанавливать MHM на отдельную виртуальную или физическую Windows-машину и связывать его с сервисом vCenter. И да, надо отметить, что:
vCenter Multi-Hypervisor Manager is a fully-supported vCenter Server feature. VMware provides support for all vCenter Multi-Hypervisor Manager or vSphere related issues
Возможности vCenter Multi-Hypervisor Manager 1.0 для хостов Hyper-V:
Добавление/удаление хостов Hyper-V в окружение vCenter
Информация о конфигурации хостов Hyper-V (processor, memory, network)
Создание/удаление виртуальных машин на Hyper-V
Удаленная консоль как к самим хостам Hyper-V, так и к виртуальным машинам
Простейшие операции по управлению питанием хостов и виртуальных машин (power off, power on, suspend, shut down guest и reset)
Изменение настроек виртуальных машин: память, vCPU, диски, сетевые адаптеры и прочее виртуальное "железо"
Отображение задач для хостов Hyper-V и виртуальных машин на общей панели задач и событий vSphere Client
Интегрированная авторизация с vCenter, а также поддержка механизма пользователей и ролей
Скачать VMware vCenter Multi-Hypervisor Manager 1.0 можно по этой ссылке. Есть еще FAQ в KB 2037570.
Как знают пользователи решения для виртуализации настольных ПК VMware View, в данном решении для доступа пользователей к своим десктопам используется протокол PCoIP, разрабатываемый компанией Teradici при поддержке VMware. Мы уже писали о настройках протокола PCoIP, а также утилите, позволяющей их регулировать из графического интерфейса, а сегодня расскажем о калькуляторе для расчета необходимой полосы пропускания PCoIP.
Называется этот калькулятор "PCoIP Protocol Bandwidth Planning Calculator", он доступен для загрузки по этой ссылке (в форму можно забить ерунду - подтверждения через почту не потребуется).
Интересно то, что это уже четвертая версия калькулятора PCoIP, которая выглядит весьма навороченно и серьезно. Для планирования доступен как корневой датацентр компании, так и филиалы, для которых рассчитывается необходимая суммарная пропускная способность, которую нужно обеспечить при внедрении решений для виртуализации ПК.
Помимо, собственно, калькулятора в документе приведен детальный план по достижению оптимальной конфигурации инфраструктуры доступа VMware View. На последнем листе xls-файла доступна таблица с рекомендованными полосами пропускания, которые нужно выделять для различных типов нагрузок в виртуальных ПК, а также настройками параметров тонкой настройки протокола PCoIP:
Это краткая версия таблицы - при необходимости ее можно развернуть и получить, например, такую картинку.
В начале прошлого года мы рассказывали о средстве VMware vCloud Connector, которое позволяет мигрировать виртуальные машины на платформе VMware vSphere из частного облака предприятия в публичное хостинг-провайдера и обратно, что может пригодиться в условиях мгновенной нехватки аппаратных ресурсов. vCloud Connector представляет собой бесплатный плагин к VMware vCenter (управляется через Web Client), с помощью которого пользователь своей частной виртуальной инфраструктуры может перемещать свои виртуальные машины в облако, т.е. к провайдеру, который дает виртуальную инфраструктуру в аренду. Происходит это, в том числе, с использованием VMware vCloud API.
С момента нашей прошлой заметки продукт существенно изменился, а на VMworld Europe 2012 была анонсирована версия vCloud Connector 2.0 (надо отметить, что пока текущая версия vCloud Connector 1.5 не поддерживает vCloud Director 5.1). Теперь это решение разделено на 2 версии:
Free Edition
Advanced Edition (в составе комплекта vCloud Suite)
Какие возможности появились в бесплатном VMware vCloud Connector 2.0 Free:
Improved Workload Tranfer - улучшенные технологии передачи данных и совместимости, позволяющие мигрировать виртуальные машины между частным облаком VMware vSphere, vCloud Director и сертифицированными сервисами vCloud (всего более 15 провайдеров, но в ближайшей перспективе - более 160).
New User Interface and Features – улучшенный интерфейс, предоставляющий возможности кросс-облачного поиска (о как!) виртуальных машин или шаблонов по имени.
Multi-tenant vCloud Connector (VCC) node – улучшенные возможности для внедрения vCloud Connector в гибридных облаках.
В коммерческом издании VMware vCloud Connector 2.0 Advanced появились следующие возможности:
DataCenter Extention – возможность растягивания сети датацентра компании на ЦОД провайдера на уровне layer 2 через защищенный туннель SSL VPN (посредством VXLAN). Это позволяет переместить виртуальную машину в ЦОД сервис-провайдера, сохранив ее IP-адрес, и продолжать управлять ей так, как будто бы она исполняется в собственном датацентре.
Content Sync - позволяет иметь один централизованный каталог виртуальных сервисов (vApp), который будет реплицироваться на удаленные каталоги (например, у различных сервис-провайдеров), которые вы можете использовать для создания новых виртуальных машин. Эти каталоги могут быть "подписаны" на исходный каталог.
Обидно, конечно, что поддержка VXLAN доступна только в платной версии, ну да ладно. Скачать VMware vCloud Connector можно по этой ссылке.
Многие знают компанию StarWind как производителя средства номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN под виртуальные машины VMware vSphere. Не так давно вышла обновленная версия StarWind iSCSI SAN 6.0 этого решения. Но, как известно, StarWind предлагает еще и отказоустойчивое решение для серверов Hyper-V.
15 ноября компания StarWind сделала 3 важных анонса, которые вам будут, безусловно, интересны:
Во-первых, вышла новая версия продукта под гипервизор Microsoft Hyper-V: StarWind Native SAN 6.0 (документ с описанием новых возможностей вот тут)
Во-вторых, вышла финальная версия решения для резервного копирования виртуальных машин на VMware vSphere, поставляемого в виде плагина - VMware Backup Plug-in. Теперь продукт полностью поддерживает новую платформу VMware vSphere 5.1.
Поскольку из этих новостей самая интересная - третья, то мы расскажем о бесплатном продукте StarWind Native SAN for Hyper-V Free edition. Он позволяет построить небольшой, но отказоустойчивый кластер хранилищ из двух серверов Microsoft Hyper-V на основе протокола iSCSI, без необходимости вложений во что бы то ни было - серверы под СХД или лицензии. Можно взять 2 обычных хост-сервера Hyper-V и забацать кластер.
Давайте взглянем на отличие бесплатного продукта от его платной версии:
StarWind Native SAN for Hyper-V
Free Edition - бесплатно
Small Business
Midsize Business
Enterprises
Компоненты продукта
Лицензируемая емкость хранилищ
Не ограничена
(HA-хранилище ограничено размером 128 ГБ)
1 ТБ / 2 ТБ (HA)
4 ТБ / 8 ТБ (HA)
16 ТБ/Не ограничено (HA)
Централизованное управление
StarWind Console
StarWind Console
StarWind Console
StarWind Console
Число серверов, входящее в лицензию
2
2 или 3
2 или 3
2 или 3
Число одновременных соединений по iSCSI к хранилищам
Из таблицы видно, что бесплатная версия StarWind Native SAN for Hyper-V Free edition практически ничем не отличается от платной, кроме ограничения на размер отказоустойчивого хранилища в 128 ГБ. Полное сравнение платного и бесплатного изданий StarWind Native SAN for Hyper-V доступно по этой ссылке.
Если вам требуется удобный поиск и навигация по большим созданным профилям хостов, созданным с помощью функций VMware vSphere Host Profiles, то можно сделать их экспорт в формат VPF (VMware Profile Format):
Затем в получившемся файле поменять расширение с *.vpf на *.xml и открыть его в своем любимом просмотрщике XML:
Мы уже не раз затрагивали тему vswp-файлов виртуальных машин (файлы подкачки), которые используются для организации swap-пространства гипервизором VMware ESXi. Эти файлы выполняют роль последнего эшелона среди техник оптимизации памяти в условиях недостатка ресурсов на хосте. Напомним, что в гипервизоре VMware ESXi есть такие техники как Transparent Page Sharing, Memory Ballooning, a также Memory Compression, которые позволяют разбираться с ситуациями нехватки памяти, необходимой виртуальным машинам.
Напомним также, что первым эшелоном оптимизации памяти является техника Memory Ballooning. Она работает за счет использования драйвера vmmemctl.sys (для Windows), поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС (если ее много), и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).
Однако, когда памяти у всех виртуальных машин совсем мало или отдельной ВМ ее требуется больше, чем сконфигурировано, а также происходит постоянное обращение к памяти (особенно, если в гостевых ОС нет VMware Tools), гипервизор начинает использовать vswp-файл подкачки, который по умолчанию находится в папке с виртуальной машиной. Мы уже писали о том, что в целях повышения быстродействия можно положить vswp-файлы виртуальных машин на локальные SSD-хранилища серверов ESXi, а также о том, как удалять мусорные файлы vswp.
Ниже мы приведем 8 фактов о swap-файлах виртуальных машин, которые основаны на вот этой заметке Фрэнка Деннемана:
1. Хранение vswp-файлов на локальных дисках сервера ESXi (в том числе Swap to Host Cache) увеличивает время vMotion. Это очевидно, так как приходится копировать vswp-файл в директорию ВМ (или другую настроенную директорию), чтобы его видел целевой хост.
2. С точки зрения безопасности: vswp-файл не чистится перед созданием. То есть там лежат не нули, а предыдущие данные блоков. Напоминаем, что размер файла подкачки равен размеру сконфигурированной памяти ВМ (если не настроен Reservation). Если же у машины есть Reservation, то размер vswp-файла определяется по формуле:
То есть, если в настройках памяти машины ей выделено 4 ГБ, а Reservation настроен в 1 ГБ, то vswp-файл будет составлять 3 ГБ.
3. Как происходит копирование vswp-файла при vMotion? Сначала создается новый vswp-файл на целевом хосте, а потом копируются только swapped out страницы с исходного в целевой vswp-файл.
4. Что происходит при разнице в конфигурации размещения vswp-файлов в кластере и для отдельных хостов? Напомним, что в настройках кластера VMware vSphere есть 2 опции хранения vswp-файлов: в папке с ВМ (по умолчанию) и в директории, которая указана в настройках хоста:
Если на одном хосте настроена отдельная директория для vswp, а на другом нет (то есть используется папка ВМ), то при vMotion такой виртуальной машины vswp-файл будет скопирован (в папку с ВМ), несмотря на то, что целевой хост видит эту директорию на исходном.
5. Обработка файлов подкачки при нехватке места. Если в указанной директории не хватает места для свопа ВМ, то VMkernel пытается создать vswp-файл в папке с ВМ. Если и это не удается, то виртуальная машина не включается с сообщением об ошибке.
6. vswp-файл лучше не помещать на реплицируемое хранилище. Это связано с тем, что используемые страницы памяти, находящиеся в двух синхронизируемых файлах, будут постоянно реплицироваться, что может вызывать снижение производительности репликации, особенно если она синхронная и особенно при vMotion в недефолтной конфигурации (когда происходит активное копирование страниц и их репликация):
7. Если вы используете снапшоты на уровне хранилищ (Datastore или LUN), то лучше хранить vswp-файлы отдельно от этих хранилищ - так как в эти снапшоты попадает много ненужного, содержащегося в своп-файлах.
8. Нужно ли класть vswp-файлы на хранилища, которые развернуты на базе thin provisioned datastore (на уровне LUN)? Ответ на этот вопрос зависит от того, как вы мониторите свободное место на тонких лунах и устройствах своего дискового массива. При создании vswp-файла VMkernel определяет его размер и возможность его создания на уровне хоста ESXi, а не на уровне устройства дискового массива. Поэтому если vswp-файл активно начнет использоваться, а вы этого не заметите при неправильной конфигурации и отсутствии мониторинга тонких томов - то могут возникнуть проблемы с их переполнением, что приведет к сбоям в работе ВМ.
Мы уже немало писали о методах и технических средствах защиты персональных данных, реализованных в продукте номер 1 - vGate R2, предназначенном для защиты виртуальной инфраструктуры VMware vSphere. А именно:
На вебинаре были представлены требования к защите персональных данных при их обработке в информационных системах, установленные только что принятым Постановлением Правительства РФ от 01.11.2012 № 1119, чем они отличаются от тех, что содержались в утратившем силу Постановлении 2007 г. № 781, что ждать дальше и что надо делать уже сегодня.
Как мы уже писали, компания Veeam Software недавно обновила свой флагманский продукт для резервного копирования и репликации виртуальных машин до версии Veeam Backup and Replication 6.5. О новых возможностях решения, кстати, можно узнать из весьма наглядного видео ниже:
Как многие помнят, у компании Veeam есть традиция бесплатно раздавать лицензии на свои продукты специалистам по решениям VMware и Microsoft. Версия 6.5 не стала исключением. Если вы хотите получить лицензию на Veeam Backup and Replication 6.5 на 2 CPU сервера ESXi для вашей тестовой лаборатории, то проследуйте по ссылкам ниже:
Если вы VMware vExpert, VMware Certified Professional (VCP) или VMware Certified Instructor (VCI) - вам сюда.
Если же вы Microsoft MVP, MCP или MCTS - то вам сюда.
Не так давно мы писали о политиках ценообразования для облачной IaaS-платформы Microsoft Azure, которая позволяет брать виртуальные машины с Microsoft Windows или Linux в аренду для организаций (сейчас находится в стадии Preview - что-то вроде бета-версии). Как известно, у Microsoft под цели Azure выделено несколько датацентров (каждый из которых дублирован в соответствующем регионе):
US North Central – Chicago, IL
US South Central – San Antonio, TX
West Europe – Amsterdam
North Europe – Dublin
East Asia – Hong Kong
South-East Asia – Singapore
Есть даже интересное видео про то, как эти датацентры устроены, и как они работают:
На их строительство и ввод в эксплуатацию было затрачено аж 2,5 миллиарда грина. Скоро будет построено еще 13 датацентров, что намекает на то, что Microsoft серьезно рассчитывает получить немалую прибыль с облачного бизнеса.
Однако тут обнаруживаются интересные вещи, касающиеся доступности IaaS-сервисов Azure. На конференции Microsoft TechEd, проходившей в июне 2012 года, были показаны следующие показатели доступности в рамках SLA для пользователей Microsoft Azure:
Как мы видим, для одиночных ВМ гарантируемый показатель доступности на 0,05 ниже, чем для тех приложений, ВМ которых дублированы (а доступ осуществляется, например, через балансировщик). Это ок.
А вот, что было показано уже в октябре 2012 года на конференции Build (пруф на 36-й минуте этого видео):
Куда делся SLA для виртуальной машины, архитектура приложения в которой не подразумевает дублирование на уровне нескольких экземпляров ВМ? Его просто нет. SLA исчез. Это значит, что такая машина Azure может простаивать не 8,75 часов в год, а все 875 часов, и Microsoft ничего за это не будет. Вот такие вот "облака" у Microsoft.
RSS
(128 ГБ)
